| Technote IM_ERRATA 02 | October 1994 |
Topics
The description of Figure 1-7 is incorrect. The paragraph immediately following Figure 1-7 should read: "In Figure 1-7, Application 2 has almost exhausted its application heap. As a result, it has requested and received a large block of temporary memory. Application 2 can use the temporary memory in whatever manner it desires."
Correction to Documented Default Stack Sizes
Pages 1-39 through 1-40, Changing the Size of the Stack
The documentation states that by default the stack can grow to "32KB on computers with Color QuickDraw" (page 1-40). The actual default stack size on machines with Color QuickDraw is 24KB. In addition, the default stack size for a background-only application (or a "faceless background process") is 2KB, not 8KB as claimed on page 1-40.
Addendum to Description of SetApplLimit
Pages 1-39, 1-52, 2-84.
The description of the SetApplLimit routine should mention that SetApplLimit enforces a minimum stack size equal to DefltStack. For example, calling SetApplLimit on a background-only application running on a Color QuickDraw machine will result in a minimum stack size of 24KB, regardless of the value passed to SetApplLimit. The partition of the background-only application must be large enough to accommodate a stack of that size.
Correction to Return Value Type
Page 1-45, Allocating Blocks of Memory
The application-defined function NewPtrCushion (defined in Listing 1-7) should return a value of type Ptr, not of type Handle.
Correction to NewPtr Description
Pages 1-58 through 1-59, 2-36.
The Assembly-Language Information for the NewPtr function states that on entry register A0 contains the number of logical bytes requested. In fact, register D0 should contain the number of logical bytes requested.
Listing 2-3 on page 2-12 contains an error. The line
TempMemCallsAvailable := BAND(myRsp, gestaltTempMemSupport) <> 0;
should be replaced by the line:
TempMemCallsAvailable := BTst(myRsp, gestaltTempMemSupport);Clarification of 'sysz' Resources and System Extensions
The documentation implies (page 2-13) that system extensions running under System 7.0 and later do not need to have 'sysz' resources to indicate their system heap memory requirements. This statement is misleading. Any system extension that needs more than 16KB should include an 'sysz' resource, no matter what the system software version.
Clarification of Block Alignment Boundaries
Page 2-22, Block Headers
The documentation states that "on computers containing the MC68020, MC68030, or MC68040 microprocessors, blocks are padded to 4-byte boundaries." This is incorrect for 68040 machines, where blocks are aligned on 16-byte boundaries.
Clarification of Block Header Diagrams
Pages 2-22 through 2-23, Block Headers
Figures 2-1 (page 2-22) and 2-2 (page 2-23) might be misleading. Remember that Inside Macintosh typically draws memory diagrams with the low-memory addresses nearest to the bottom of the diagram. (Compare Figure 1-1 on page 1-5, where the low memory end of the diagram is explicitly labeled.) The longword containing the block type and size correction is the first longword in the 24-bit zone header header. Similarly, the longword containing the block type and unused space is the first longword in the 32-bit zone header.
Figure 2-2 (page 2-23) claims that a block type of "11" signifies a relocatable block. This is incorrect. The correct type indicator for a relocatable block is "10".
The Assembly-Language Information for the LockMemoryContiguous function states that on entry register A1 contains the "number of bytes to unlock." In fact, register A1 contains the number of bytes to lock.
Correction to DebuggerGetMax Description
Page 3-34
The description of DebuggerGetMax states (page 3-34): "Of course, you should use the Gestalt function to check whether virtual memory is available before you call the DebuggerGetMax function." It is preferable to check to see whether the _DebugUtil trap is available rather than call Gestalt to see if virtual memory is available.
Correction to DebuggerLockMemory Description
Page 3-37
The Assembly-Language Information for the DebuggerLockMemory function (page 3-37) lists the trap macro as _DebuggerLockMemory. The correct trap macro should be _DebugUtil. Also, the Assembly-Language Information for the DebuggerLockMemory function states that on entry register A1 contains the "number of bytes to hold." In fact, register A1 contains the number of bytes to lock.
Correction to DebuggerUnlockMemory Description
Page 3-38
The Assembly-Language Information for the DebuggerUnlockMemory function (page 3-38) states that on entry register A1 contains the "number of bytes to hold." In fact, register A1 contains the number of bytes to unlock.
Further Reference:
Main | Page One | What's New | Apple Computer, Inc. | Find It | Contact Us | Help